[レポート]Infra Study Meetup #1「Infrastructure as Code」に参加しました #InfraStudy

オペレーション部の橋本です。
2020年4月24日に開催された、Infra Study Meetup #1「Infrastructure as Code」というオンラインイベントに参加しました。
本記事はイベントの参加レポートです。

Infra Study Meetup

イベントの趣旨

connpassのイベントページより抜粋します。

本イベントは、複数回にわたりインフラ技術の各分野に精通した講師をお招きし、インフラ技術の「これまで」と「これから」を網羅的に学ぶことを趣旨として開催いたします。
Infra Study Meetup #1「Infrastructure as Code」 - connpass

いわゆる「連載」シリーズで、今回はその記念すべき第1回目のイベントでした。

アーカイブ動画

イベント本編のアーカイブ動画が公開されており、いつでも振り返り視聴が可能です。
登壇者の方々はそれぞれ資料を公開してくださっていますが、資料公開のないLTや「質疑応答」の会話でも興味深いお話をなさっています。ぜひ動画でもイベントの内容を確認ください。

基調講演「Infrastructure as Codeのこれまでとこれから」 mizzyさん

「これまでとこれから」とタイトルにある通り、IaCの成り立ちと、これからどのように利用されていくのかというお話でした。
IaCの歴史

• 元々、IaCとは「インフラをコードで記述する」こと自体を指していた
  それ以上の意味は字義的にはない
  例えば、IaCを導入することで受けられる恩恵は含まれない
• IaCという言葉の初出は2008年頃(Chefの登場の少し前)と思われる
  Chefの広がりとともにIaCという言葉も広がったが、技術的な起源はCFEngine（1993年リリース）といえる
• 黎明期はConfiguration Managementの自動化が焦点だった
• 2009年以降、ソフトウェア管理のプラクティスをシステム管理に生かそうという動きが生まれ、IaCの意味合いも変化してきた
• クラウドインフラストラクチャ等、APIでプログラマブルに扱えるIaaSやコンテナの登場により、IaCの範囲は拡大してきた

現在のIaC

• 手軽にインフラが構築できるようになったことで、新たなインフラ管理の問題が顕在化している
  サーバスプロール：管理能力を超えて乱立してしまう、いわゆる野良サーバ。
  構成ドリフト：微妙に構成・設定の違うサーバが増えることにより、同じ作業を実施してもサーバによって結果が異なることがある
  スノーフレークサーバ：他のサーバと構成・設定が異なることで、誰も作業したがらないサーバ。
  脆弱なインフラを構成する一因となる
  脆弱なインフラ：必要なパッチ適用などがなされない等のスノーフレークサーバが蔓延し、システム全体が脆弱になること。
  システム全体が簡単に壊れてしまう。
  オートメーション恐怖症:スノーフレークサーバが増えると、自動化ツールの実施結果が予測不可能になり、自動化の恩恵を十分に受けられなくなる。
  システム疲労：何もしなくても、時間の経過とともにシステムが壊れること
• サーバを手軽に立てられるようになった影響で、変更管理が破滅してシステムが壊滅状態になる。
  でもシステムの変更はしないといけない、という問題
• IaCの原則（目標にするべきこと）
  簡単に再現できるシステム
  使い捨てにできるシステム
  統一的なシステム
  反復できるプロセス
  絶えず変化するデザイン
• IaCを利用することによって、変化に強いアンチフラジャイルなインフラを目指せる
  アンチフラジャイル:システムを絶えず変更し改良することによって、堅牢になる（強くなる）
  人間の筋トレと一緒
  自動化だけではアンチフラジャイルは実現できない
  変化に対応するのは「人」であるため、人を中心にシステムを設計することが成功の秘訣

IaCのこれから

• これからはIaCが当たり前になり、わざわざIaCという言葉を使わなくなってくる
• IaCが最初に持っていた言葉の役割は終わりつつある
• ただし、IaCによって生み出された原則やプラクティスはこれからも利用され続ける

質疑応答 mizzyさん、まつもとりーさん

• IaCのアンチパターンを定義するのは難しい
  コードを書くこと自体を楽しんでいて、試行錯誤しているうちにうまくいくこともある
• IaC疲れ：IaCにチャレンジしたものの、実際にやってみたら自分たちの環境に合わず、うまくいかない状況に陥ってしまう状態
  精神的、コスト的にダメージを負って、IaCにチャレンジすることが怖くなってしまう
  トライアンドエラーも大事だと割り切って、覚悟の上で取り組む心持ちが必要
  自分たちの現行の環境に合わない、求める環境と違うということがわかるだけでも進歩である
• 過剰な再利用性を求めると、IaC疲れが発生しかねない。やりすぎ注意

LT1「Infrastructure as Codeを導入して良かった点」 Masaki Suzuki氏

• IaCの導入により、クラウドインフラストラクチャの管理工数を大幅に削減できた
• プロダクトとして一定の品質を保証できるようになった
  実行結果は誰がやっても同じなので、作業者による品質のブレ(作業手順の抜け漏れ)がない
  コードレビューによって事前にミスが防止できる
• 作業の簡素化・属人化の解消ができた
  運用コストの削減により、プロダクトの差別化を図るための事業開発などに工数を使うことができる
• リモート作業も可能で、現在の状況には最適
• いきなり全てをIaC化するのは難しい
• 少しずつで良いのでノウハウを積み上げていく意識が大事

LT2「Patterns in Infrastructure as Code」 chaspyさん

• 強制したい部分だけ共通化、モジュール化するのがポイント
  DRY原則にこだわりすぎない
• コードについて、ドキュメントに残しておくことが大事
  ソフトウェア管理・開発のコードでもコメントを残すのと同じ

LT3「Infrastracture as Code変遷 ~ やるようになったこと・やらなくなったこと」 Songmuさん

• なぜIaCなのか
  人間には信頼性がないため自動化する必要がある
  あらゆることをコードで定義すれば自動化できる
  とはいえ、上記は理想論であり現実には様々な壁がある
• コードは書いた瞬間に負債になるのは避けられないため、負債になりにくい工夫が必要
  書かなくて済むコードは書かない→コードが複雑になることを避けられる
  コードを書くという万能感に浸ってしまうと、なんでもコード化したくなる
  「負債化しない」意識を持っていないと、結局IaC疲れに陥ってしまう
• Define everything as code におけるeverythingの量を減らす
  コード化したい業務の範囲を絞る（関心ごとにフォーカスする）
• サーバプロビジョニングはコード化せず、コンテナオーケストレーションレイヤーに多くを任せる
  流行だからと言ってやるのではなく、業務に必要な範囲を見極める
  ECSのタスク定義をコード化する

LT4「究極のInfrastructure as Codeを目指して」 Shin’ya Ueokaさん

• IaCにおいて、ソースコードは開発者が作りたい理想の状態(最終的なインフラ構成)
• 現在の状態と理想の状態の差分を埋めるのが、TerraformやAnsibleなどのシステム
• 現在の状態のソースコードを理想の状態のものに変更する→本番適用
• ソースコードでの運用だとロールバックも簡単

LT5「Infrastructure as Code におけるTest-Driven Development とその差分」 Shuya Motouchiさん

• テスト駆動開発とは
  1.最初にテストを書く
  2.テストが動作する必要最低限の実装をする
  3.コードがより良くなるよう改良し、機能を洗練させる
  上記を繰り返す開発スタイルのこと
• IaCにおけるテスト駆動開発の注意点と対策 　
  インフラでは依存関係を明確に分離したテストが書きにくい

  　

  →アプリケーション側と協業することで良いテストを書きやすい

  　

  IPアドレスのチェックやDNSの設定など、テストを書くのが大変なのにテスト以外で担保できやすい

  　

  →正常な値が入っているかどうかより、異常な値が入っていないかを確認すると良い

  　

  本番環境でしか再現できない環境や状況があり、テストがしにくい(データやトラフィック、並列性など)

  　

  →負荷試験や障害試験など事前に行えるものは実施する

  　

  事前実施が難しいものは、監視などで可観測性を高めることでリスクを管理できる

  　

  テストの対象と項目数が多いと、テスト時間が長くなる

  　

  →各環境ごとに適したテストスタックを用意する(プログレッシブテストの実施)

  　

  依存関係の明確化、最小化によりテストの分離を行う(やりすぎるとコストが上がるので注意)

LT6「サービスメッシュを完全に理解する」 inductorさん

• IaCの観点からサービスメッシュに入門するためのお話
• インフラでもサービスメッシュを気にするべき
• マイクロサービスとは何か
  サービスのデータベースや処理が大きくなりすぎないよう、個々のサービスに分離すること
  サービスの分離の粒度を細かくしすぎても、やるべき処理が多くなりすぎて煩雑になる

  　

  サービスを分離したぶん、処理をスケールする必要があるが限界がある

  　

  全サービスに共通の構成をまとめた方が楽
• マイクロサービスにおける煩雑化の対策になりうるのがサービスメッシュ
• サービスメッシュとは
  マイクロサービスに共通の規約を切り出す
  サービス数が増えてもスケールできる構成管理を提供する
  上記全体をコードで管理するための仕組み
  共通設定をコード化することで、マイクロサービス構成でのインフラとアプリの間の治安を守ることができる
• サービスメッシュは下記の複雑性を解決するための手法
  構成管理を突き詰めていくと、サービス全体の複雑性を容認せざるを得なくなることがある
  マイクロサービスで作られるアプリケーションを、インフラの構成管理を担保しながら守っていく仕組みが必要

LT7「History of Infrastructure as a code testing」 yutachaosさん

• テストピラミッドによるIaCのテストの分類
  高水準テスト:実際にサービスを立ち上げて行うテスト
  中水準テスト:サーバのネットワークや設定のテスト
  低水準テスト:定義ファイルやコードの構文が正しいかどうかのテスト
• 最初期のIaCは低水準テストのツールが多かった
  chefspec,rspec-pupets
• Serverspecの登場以降は、サーバーの構成をテストするものが増えていった
  Provisioning testing的なツール
  IaaS(パブリッククラウドなど)の一般化が一因と考えられる
• ダイナミックインフラストラクチャをテストするツールもあったが、あまり利用されなかった
  コストと機能の兼ね合いによって、他のツールの方が利用された傾向
• コンテナが流行し始めてから、インフラストラクチャ定義ツールが主流になってきた
  Terraform,Kubernetesなどがインフラストラクチャ定義ツールにあたる
• 宣言的記述を用いる設定ファイルのバリデーションができるツールが流行っている
  conftest,cueなど
• 次に流行るテストツールが何であるのか楽しみ！

LT8「フルリモートにおける Infrastructure as Code の効果」 そのっつさん

• IaCの利点
  開発と同様のレビュープロセスにできる(Pull Request)
  バージョン管理が可能になる
  コードの再利用ができる
  →環境の同一性の担保がしやすい、他チームや他環境への横展開が容易になる
  手作業によるヒューマンエラーの防止
  インフラ構築もCI/CD化できる
• インフラ構築をCI/CD化する利点
  コード化されることで、途中からプロジェクトに参画したメンバーが情報を追いやすい
  デプロイ方法の自動化によりオペレーションミスが防止できる
  自動化による開発効率とリリーススピードが向上する
• リモートワークでも齟齬なくコミュニケーションを取るために、IaCやCI/CDは必須ではないか
• 手作業のインフラ構築では、リモートワークでコミュニケーション齟齬が加速する傾向にある
• コード化、自動化しない場合でも対策可能だが、工数がかなりかかる
• コード化/自動化した際の効果
  何をやったか(やる予定か)の見える化
  いつブロジェクトに参画しても、コードを追えば全体感が分かる
  デプロイも通知も自動化できる
• フルリモートワークとIaC、CI/CDは相性が良いのでやっていきましょう!

全体を通しての感想

IaCのコードそのもののテクニックより、IaCを生かせる環境や生かすための思想などが学べる良い機会でした。 また、1日で得られる情報の幅がかなり広いMeetupだったように思います。
次回以降もインフラ関連のテーマで開催されますので、継続して参加していきたいです!